Various devices, deployed as a network of nodes, have become useful for collecting and/or process data in applications such as ambient intelligence, smart environments, and autonomous control. For example, networked sensors may be deployed in a building to measure the temperature and humidity such that an air conditioning system for the building may be adjusted autonomously. These networked devices are generally referred to as constrained nodes or constrained devices in a (constrained) network, where the term “constrained” is used to express presence of limitations in terms of, e.g., power and/or computing resources. With the advent of technologies such as 6lowpan, these nodes have become easily accessible over the Internet, where each node is uniquely identifiable and where the nodes act as servers to which clients can connect (therefore, in the following, such nodes are referred to as “servers” or “server nodes”). Such a system of server nodes is sometimes referred to colloquially as “Internet of Things”. The server nodes may be in a wired network and/or a wireless network. The networks that connect these server nodes may be low power and lossy networks (LLNs).
A client may be configured to access a server node through a server-client relationship, using a protocol such as e.g. Constrained Application Protocol (CoAP). Typically, each of the server nodes has at least one REST resource, where, as used herein, the term “REST resource” refers to a source of specific information which can be referenced with a global identifier. Examples of the kind of specific information of the resource include temperature, humidity, room location, picture, or light control. An example of a global identifier is a uniform resource identifier (URI) in HTTP. Examples of identifiers of such REST resources include “http://example.org/temperature”, “/humidity”, “/room_location”, “/picture”, and “/light_control”. When a client accesses a server node, it may e.g. query the server node for the resource at the node. For example, using the (conditional) observe option of the CoAP protocol it is possible for a client to observe a resource on a sensor (e.g. sensor values) and to receive notifications of interest.
In order to properly operate, a server node needs to have access to operational state information, i.e. all state information that defines the behaviour of the server node in an operational network over time. For example, when a client establishes a relationship with a server node and the existence of this relationship results in notifications of interest being sent from the server node to the client, the operational state will determine how and which data will be sent to the client. Another example includes a situation where resources are offered in order to change protocol settings and/or parameters of the application on the server node (e.g. sensor sampling rate, sleep behavior). In such a situation, a client may interact with a server node, using CoAP, and update protocol settings via a CoAP resource. The operational state in this case determines the behavior of software/protocols running on the server node.
Since the server node needs to have operational state information available to it, this information could e.g. be stored at the server node's memory. The most relevant kinds of memory are the on-chip memory of a microcontroller (RAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), and Flash storage. EEPROM is electronic non-volatile computer storage that can be electrically erased and reprogrammed. EEPROM erasing and reprogramming is expensive in terms of memory and power consumption, is read-only and cumbersome to reprogram at run-time and is, therefore, typically used as program memory. RAM memory is mostly volatile memory that can be read/written at run-time. It is the RAM memory that is typically used for storing operational state information. As a result, some server nodes, such as e.g. low-cost sensor nodes, cannot adequately provide persistent memory at run time for storing operational state information. Even if a server node can store all operational states in its volatile memory, when the node crashes, reboots or its batteries are replaced, this information is lost and needs to be restored.
The process of restoration of the lost operational state on a server node may be referred to as “crash recovery.” Typically the parties that are able to store operational state information and perform the crash recovery to restore the lost state information are third party hosts that engage with the server nodes. One problem is then, as these hosts are often outside of the local network of the server node or even not online (e.g. third party establishment of binding between sensor and actuator), the crash detection and restore times are often unacceptably high. Another problem is that the server node needs to have additional code or intelligence that would enable the server to exchange the operational state information with a third party, which is often not feasible on a constrained device or introduces additional complexity. Yet another problem is that this approach causes additional traffic for storing operational state information, which is highly undesirable in the already limited constrained network.
One way to solve these problems could be adding to the server nodes additional persistent hardware components (e.g. Flash storage, TI's FRAM) capable of storing larger amounts of operational states in a persistent manner. However, this increases the manufacturing cost. Alternatively, operational states could be stored in a persistent way by reprogramming on the fly the EEPROM of the server node. This is typically done for over-the-air updates, but is less suited for storing operational state as it would require reprogramming the EEPROM at run-time for every change to the operational state.
What is needed in the art is a crash recovery mechanism that overcomes one or more drawbacks described above. In particular, a more lightweight mechanism is needed that does not require any modifications to the existing hardware of constrained server nodes.